home *** CD-ROM | disk | FTP | other *** search
/ EuroCD 3 / EuroCD 3.iso / Programming / vbcc / doc / vbccppc.doc < prev    next >
Text File  |  1998-06-24  |  6KB  |  184 lines
  1. vbcc - C compiler (c) in 1995-97 by Volker Barthelmann
  2.  
  3.  
  4. INTRODUCTION
  5.  
  6.     vbcc is a free portable and retargetable ANSI C compiler.
  7.     It is clearly split into a target independant and a target dependant
  8.     part and supports emulating datatypes of the target machine on any
  9.     other machine so that it is possible to e.g. make a crosscompiler for
  10.     a 64bit machine on a 32bit machine.
  11.     This document only deals with the target dependant parts of the
  12.     PowerPC version.
  13.  
  14.     This is a beta version!
  15.  
  16.  
  17. LEGAL
  18.  
  19.     vbcc is (c) in 1995-97 by Volker Barthelmann. All code is written by me
  20.     and may be freely redistributed as long as no modifications are made
  21.     and nothing is charged for it.
  22.     Non-commercial usage of vbcc is allowed without any restrictions.
  23.     Commercial usage needs my written consent.
  24.  
  25.     Sending me money, gifts, postcards etc. would of course be very nice
  26.     and may encourage further development of vbcc, but is not legally or
  27.     morally necessary to use vbcc.
  28.  
  29.  
  30. ADDITIONAL OPTIONS FOR THIS VERSION
  31.  
  32.     -merge-constants
  33.  
  34.                 Place identical floating point constants at the same
  35.                 memory location. This can reduce program size and increase
  36.                 compilation time.
  37.  
  38.     -const-in-data
  39.  
  40.                 By default constant data will be placed in the .rodata
  41.                 section. Using this option it will be placed in the data
  42.                 section.
  43.                 Note that on operating systems with memory protection this
  44.                 option will disable write-protection of constant data.
  45.  
  46.     -fsub-zero
  47.  
  48.                 Use fsub to load a floating-point-register with zero.
  49.                 This is faster but requires all registers to always contain
  50.                 valid values (i.e. no NaNs etc.) which may not be the case
  51.                 depending on startup-code, libraries etc.
  52.  
  53.     -amiga-align
  54.  
  55.                 Do not require any alignments greater than 2 bytes.
  56.                 This is needed when accessing Amiga system-structures, but
  57.                 can cause a performance penalty.
  58.  
  59.     -elf
  60.  
  61.                 Do not prefix symbols with '_'. Prefix labels with '.'.
  62.  
  63.     -no-regnames
  64.  
  65.                 Do not use register names but only numbers. This is necessary
  66.                 to avoid name-conflicts when using -elf.
  67.  
  68.     -setccs
  69.  
  70.                 The V.4 ABI requires that when varargs-functions are called
  71.                 with arguments passed in the floating-point registers this
  72.                 has to be signalled in a certain bit of the condition code
  73.                 register. vbcc usually doesn't make use of this and
  74.                 therefore does not care about that bit by default.
  75.                 This may lead to problems if you link objects compiled by
  76.                 vbcc to objects not compiled by vbcc (e.g. a different
  77.                 C-library) and call varargs-functions with floating-point
  78.                 arguments.
  79.                 In this case -setccs might help.
  80.  
  81.  
  82. SOME INTERNALS
  83.  
  84.     The current version generates assembly output for use with the "pasm"
  85.     assembler by Frank Wille. The generated code should work on 32bit systems
  86.     based on a PowerPC CPU using the V.4 ABI.
  87.  
  88.     The register names are:
  89.  
  90.         r0 through r31 for the general purpose registers,
  91.         f0 through f31 for the floating point registers and
  92.         cr0 through cr7 for the condition-code registers.
  93.  
  94.     The registers r0, r3-r12, f0-f13 and cr0-cr1 are used as scratch registers
  95.     (i.e. they can be destroyed in function calls), all other registers are
  96.     preserved. r1 is the stack-pointer and r13 is the small-data-pointer if
  97.     small-data-mode is used.
  98.  
  99.     The first 8 function arguments which have integer or pointer types
  100.     are passed in registers r3 through r10 and the first 8 floating-point
  101.     arguments are passed in registers f1 through f8. All other arguments
  102.     are passed on the stack.
  103.  
  104.     Integers and pointers are returned in r3, floats and doubles in f1.
  105.     All other types are returned by passing the function the address
  106.     of the result as a hidden argument - so when you call such a function
  107.     without a proper declaration in scope you can expect a crash.
  108.  
  109.     The elementary data types are represented like:
  110.  
  111.     type        size in bits        alignment in bytes (-amiga-align)
  112.  
  113.     char                8                       1 (1)
  114.     short              16                       2 (2)
  115.     int                32                       4 (2)
  116.     long               32                       4 (2)
  117.     all pointers       32                       4 (2)
  118.     float              32                       4 (2)
  119.     double             64                       8 (2)
  120.  
  121.  
  122. STDARG
  123.  
  124.     A possible <stdarg.h> could look like this:
  125.  
  126.     typedef struct {
  127.       int gpr;
  128.       int fpr;
  129.       char *regbase;
  130.       char *membase;
  131.     } va_list;
  132.  
  133.     char *__va_start(void);
  134.     char *__va_regbase(void);
  135.     int __va_fixedgpr(void);
  136.     int __va_fixedfpr(void);
  137.  
  138.     #define va_start(vl,dummy) \
  139.       ( \
  140.         vl.gpr=__va_fixedgpr(), \
  141.         vl.fpr=__va_fixedfpr(), \
  142.         vl.regbase=__va_regbase(), \
  143.         vl.membase=__va_start() \
  144.       )
  145.  
  146.     #define va_end(vl) (vl.regbase=vl.membase=0)
  147.  
  148.     #define __va_size(type) ((sizeof(type)+3)/4*4)
  149.     #define va_arg(vl,type) \
  150.       (__typeof(type)&15)>8? \
  151.         (vl.membase+=__va_size(type),((type*)vl.membase)[-1]) \
  152.       : \
  153.        ( \
  154.         (((__typeof(type)&15)==5||(__typeof(type)&15)==6)) ? \
  155.          ( \
  156.           ++vl.fpr<=8 ? \
  157.              ((double*)(vl.regbase+32))[vl.fpr] \
  158.           : \
  159.             (vl.membase+=__va_size(type),((type*)vl.membase)[-1]) \
  160.          ) \
  161.         : \
  162.          ( \
  163.           ++vl.gpr<=8 ? \
  164.             ((int*)(vl.regbase+0))[vl.gpr] \
  165.           : \
  166.             (vl.membase+=__va_size(type),((type*)vl.membase)[-1]) \
  167.          ) \
  168.        ) \
  169.  
  170.  
  171. KNOWN PROBLEMS
  172.  
  173.     - generated code is not very good
  174.     - nested function calls which pass parameters on the stack will not work
  175.     - composite types are put on the stack rather than passed via pointer
  176.     - indication of fp-register-args with bit 6 of cr is not done well
  177.  
  178.  
  179. Volker Barthelmann                                      volker@vb.franken.de
  180. Kennedy-Ring 39
  181. 91301 Forchheim
  182. Germany
  183.  
  184.